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1  Introduction 


Tactical  Small  Units  (TSU)  (battalion  [300-1000  soldiers]  and  below)  currently 
establish  non-standardized  base  camps  for  contingency  operations  (contingency 
basing),  potentially  limiting  their  ability  to  efficiently  employ  Full  Spectrum1  operations 
by  placing  the  TSU  with  reduced  capability.  The  TSU  may  not  be  able  to  effectively 
support  the  modern  Full  Spectrum  battlefield  demands  unless  contingency  basing 
capabilities  specific  to  the  TSU  are  combined  as  a  single,  integrated,  agile,  force 
projection  platform.  A  contingency  base  should  provide  Soldiers  with  an  effective, 
logistically  supportable,  affordable,  and  rapidly  deployable  environment  to  project  force 
across  the  Full  Spectrum  of  operations.  The  U.S.  Army  Research,  Development  and 
Engineering  Command  (RDECOM)  and  the  various  Program  Executive  Office  (PEO) 
and  Program  Management  (PM)  stakeholders  working  together  must  develop  a 
contingency  basing  capability  -  along  with  a  development  planning  process  —  that  will 
enable  an  Army  enterprise  approach  to  capability  delivery  for  the  tactical  edge  with  total 
system  integration  aligned  to  Army  Modernization  strategies  and  ARFORGEN  (Army 
FORce  GENeration).  As  such,  the  U.S.  Army’s  transformation  and  force  structure 
changes  have  resulted  in  a  reduced  capability  regarding  training,  planning,  management 
and  expertise  available  to  the  Army  units  as  they  establish,  maintain,  sustain  and 
transition  a  contingency  base  through  its  life  cycle.2 

This  research  focused  on  specific  aspects  of  Tactical  Small  Unit-Contingency  Basing 
(TSU-CB),  as  a  force  projection  platform  and  a  potential  means  to  address  the 
interrelated  individual  Soldier  and  TSU  load  (cognitive  and  physical)  using  methods  and 
tools  developed  for  systems  engineering.  The  research  task  is  to  develop  a  set  of 
interrelated  processes,  mechanisms,  and  tools  to  capture,  explain,  and  manage  the 
complex  operational  and  system  interaction  posed  by  the  dynamic  nature  of  the  TSU 
operations,  along  with  a  means  to  measure  progress.  The  TSU  exhibits  a  complex, 
pluralistic,  set  of  requirements  across  a  number  of  factors  ill-suited  to  standard  system 
engineering  practices.  Novel  means  to  optimize  TSU-CB  need  to  be  considered. 

The  primary  operational  outcomes  being  sought  are: 

•  Reduced  vulnerabilities  and  losses:  Human,  systems,  and  information 

•  Reduced  sustainment  demands:  Substantially  reduce  supply  convoy 
requirements  by  implementing  self-sustaining  and  “right-sized”  basing 
capabilities  with  special  emphasis  on  fuel,  water  and  waste. 


1  The  Army  defines  Full  Spectrum  operations  as  the  combination  of  offensive,  defensive,  and  either  stability 
operations  overseas  or  civil  support  operations  on  U.S.  soil  (US  Army  Training  and  Doctrine  Command,  The  Army 
Operating  Concept  2016  -  2028,  TRADOC  Pamphlet  525-3-1,  dated  19  August  2010. 

2 

https://secureweb2.hqda.pentagon.mil/vdas_armyposturestatement/2011/information_papers/PostedDocument.as 

p?id=i26 
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•  Cost  effective  choices  and  solutions:  Innovation  that  targets  life  cycle 
affordability;  sustainment  cost  savings  re-directed  to  resource  DOTMLPF 
integrated  solutions. 

•  Effectively  trained  and  ready  Soldiers  and  planners  with  contingency  basing  skills 
effectively  distributed  throughout  the  Operating  and  Generating  Force. 

•  Reduced  Contingency  Basing  manpower  burden  on  operational  mission  forces: 
yielding  a  Force  Multiplier  effect. 

•  Reduced  time,  material,  equipment  and  personnel  requirements  for  Base 
Construction/  Deconstruction:  Modular,  scalable,  adaptable;  re-deployable 
“fighting  bases.”  Informed  by  existing  contingency  construction  planning  and 
management  systems  and  tools. 

•  Enhanced  interoperability  with  Joint,  Inter-Agency,  Inter-Governmental  and 
Multi-National  (JIIM)  partners.  Informed  by  coalition  partner  practices. 

•  Reduced  Environmental,  Safety  and  Occupational  Health  (ESOH)  Risks. 

The  processes  and  tools  need  to  enable  the  measurement  and  assessment  of 
improvements  based  on  new  and  emerging  technologies  that  will  be  integrated  as 
capability  packages  into  the  ARFORGEN  process. 

Thus,  this  research  was  a  collaboration  among  the  Systems  Engineering  Research 
Center  (SERC),  RDECOM  and  its  respective  Research  and  Development  Engineering 
Centers  (RDECs),  Army  support  functions  (such  as  PEO  Combat  Support  &  Combat 
Service  Support,  Training  and  Doctrine  Command,  PEO  Integration,  and  Assistant 
Secretary  of  the  Army  for  Acquisition,  Logistics  and  Technology,  to  name  a  few),  and  the 
Army  user  community.  Below  are  seven  sub  tasks  that  were  in  response  to  the  above 
stated  eight  objectives.  For  the  first  year  of  this  research  task,  only  three  of  the  sub  tasks 
were  executed  and  will  be  reported  up  on  in  this  Final  Technical  Report.  All  sub-tasks 
are  summarized  below,  and  those  sub-tasks  not  supported  are  identified  in  italics. 

1.  Focus  on  initial  system  boundaries  and  connections  in  order  to  facilitate 
early  dynamic  modeling.  In  order  to  separate  the  critical  few  from  the  trivial 
many,  SERC  shall  work  with  NSRDEC  researchers  and  chief  engineers  to  create  an 
abstraction  of  the  whole  Contingency  Basing  and  Soldier  Load  scope  that  can  be 
animated  at  a  early  stage  as  a  guide  to  identify  the  critical  components  and  aspects 
that  will  need  priority  of  scrutiny  on  order  to  create  high-fidelity  models.  This  will  be 
achieved  by  creating  high-level  systemigrams  and  system  models  for  Soldier  load 
and  Contingency  Basing.  In  addition,  identify  means  to  create  initial  value/risk 
based  design  objectives  and  functions  on  a  reduced  (and  thus  manageable) 
constraint  space.  Consistent  with  this  work,  SERC  will  provide  expert  input  to 
capability  capture,  analysis  and  value  risk  capture. 

2.  Model-based  systems  engineering  (A).  As  Contingency  Basing  is  emerging, 
there  is  a  proliferation  of  separate,  individual  models:  business  case/cost,  functional 
decomposition,  virtual,  logical,  Sandia  logistical  support,  and  SysML,  to  name  a  few. 
It  will  be  difficult  to  keep  these  models  in  synchronization  —  linked  -  especially 
during  the  early  work  on  this  initiative.  A  conceptual  framework  for  “holistic” 
modeling  support  for  complex  initiatives  such  as  Contingency  Basing  need  to  be 
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explored.  In  addition,  SERC  could  help  the  Army  create  specifications  for  the 
interoperability  of  the  many  CB  models,  an  area  of  active  research.  The  goal  is  to 
anticipate  model  compatibility  problems  and  prevent  them.  Furthermore,  the  model- 
based  system  could  be  used  to  look  for  patterns,  such  as  program  protection 
exposure,  architecture  for  resilience,  incomplete  vignettes,  and  technology  insertion 
candidates. 

3.  Model-based  systems  engineering  (B).  Network  models  will  be  created  to 
identify  features  that  belong  together.  Contingency  basing  is  awash  in  functions, 
tasks,  views,  data,  connections,  causes,  time  orderings,  priorities,  and  linkages.  Have 
any  been  missed?  One  way  to  ascertain  this  is  to  ask  a  wide  scope  of  experts  who 
normally  operate  in  siloed  organizations  about  what  should  be  connected  to  what 
else  —  using  social  networking  tools.  The  collective  linkage  network  can  then  be 
interrogated  to  see  if  the  already  documented  connections  account  for  the  clumps, 
cliques,  and  cluster  suggested  by  an  array  of  specialized  experts.  In  addition,  a 
specific  perspective  to  prioritize  functions  will  be  provided  relative  to  a  number  of 
dimensions,  such  as  time-ordering,  socio-political  factors,  regulations,  doctrine,  etc. 

4.  Help  assess  and  formalize  Developmental  Planning  Process  and 
Practices  within  the  US  Army.  Based  on  the  established  and  piloted  Air  Force 
Research  Laboratory’s  Concept  Characterization  and  Technical  Description 
process  (its  version  of  early  life  cycle  Developmental  Planning,  Air  Force  Research 
Laboratory  Instruction  61-104,  Science  and  Technology),  SERC  researchers  will 
work  with  the  Contingency  Basing  leads  to  tailor  this  early  systems  engineering 
standard  to  Army  needs.  The  Air  Force  standard  is  one  of  the  few  early  SE 
development  processes  that  has  been  in  place  long  enough  for  lessons  learned  to 
accumulate  and  to  inform  both  the  standard  and  its  application  in  the  science  and 
technology  area. 

5.  User  CB  workbench.  In  addition,  the  model-based  system  would  function  as  a 
user  workbench  where  a  combatant  commander  could  explore  options  for 
configuring  contingency  bases.  While  there  would  be  significant  computing 
capability  “under  the  hood,”  the  user  would  see  models  only  in  his/her  terms.  And 
as  field  knowledge  of  contingency  bases  grows,  the  workbench  would  grow  in 
fidelity  and  decision  support.  SERC  will  help  to  create  the  specification  and  pilot 
instances  of  this  Workbench. 

6.  Visualizing  an  “ infinity ”  of  data.  All  of  the  permutations  and  combinations  of 
the  input  space  will  produce  a  flurry  of  base  configurations.  How  will  one  be  able  to 
make  sense  of  all  of  the  combinations  of  inputs  and  then  be  able  to  react  sensibly  to 
the  output?  Visualization  technology  helps  engineers  see  patterns  in  high¬ 
dimensional  data.  Imagine  all  of  the  possible  outcomes  with  just  the  few  input 
categories  suggested  by  the  Corps  of  Engineers:  time,  size,  mission  type,  base 
systems,  operations  tempo,  and  human  dimensions,  resulting  in  a  spectrum  of 
recommendations  about  configuration  and  duration  (expeditionary,  temporary, 
and  enduring).  To  this  add  the  vagaries  of  the  consumption  data,  such  as  water  per 
day  per  Soldier,  energy  consumption  per  day  per  Soldier,  etc.  SERC  will  aid  the 
Contingency  Basing  team  experiment  with  and  weigh  features  of  visualization 
systems  as  a  way  to  reason  from  the  dense  space  of  data. 
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7.  Assessment  and  improvement  of  SoS  engineering  methods.  Validation 
and  verification  (V&V)  of  Contingency  Basing  concepts  and  early  formulation  will 
be  difficult  because  in  its  current  form  it  is  an  applied  practice,  the  kind  that  can 
best  be  validated  only  in  the  field,  such  as  at  the  Systems  Integration  Lab  at  Ft. 
Devens.  But  that  would  be  very  late  in  the  conceptual  life  cycle  to  find  errors,  so  a 
form  of  early  V&V  is  required.  SERC  researchers  working  with  the  Army  would 
develop  improved  verification  and  validation  approaches  for  SoS  via  models  and 
formal  methods.  It  would  be  desirable  to  verify  and  validate  at  the  functional  level, 
rather  than  delay  every  time  to  the  final  material  solution.  It  would  also  be 
desirable  to  understand  a  model  based  paradigm  that  allows  a  more  expedient 
synthesis,  analysis,  and  evaluation  of  the  problem  and  potential  array  of  solutions, 
and  allow  trade  space  exploration  and  a  better  understanding  of  the  resilience  of 
the  architecture  and  deployment.  Accordingly,  we  propose  an  exploration  of  deep 
systems  engineering  practices  that  would  formalize  the  characterization  of  testable 
properties  as  a  long-term  improvement  for  what  will  appear  as  conventional 
engineering  in  the  early  days  of  the  Contingency  Basing  initiative. 
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2  FOCUS  ON  INITIAL  SYSTEM  BOUNDARIES  AND  CONNECTIONS  IN 
ORDER  TO  FACILITATE  EARLY  DYNAMIC  MODELING 


The  Department  of  Defense  (DoD)  is  vigorously  pursuing  greater  efficiency  and 
productivity  in  defense  spending  so  it  can  continue  to  provide  the  armed  forces  with 
superior  capabilities  in  an  environment  of  flat  defense  budgets.  Toward  that  end,  the 
Office  of  the  Secretary  of  Defense  (OSD)  has  issued  new  acquisition  guidance  that  places 
increased  emphasis  on  system  engineering  early  in  the  lifecycle  to  balance  operational 
performance  with  affordability.  In  response  to  this,  some  DoD  efforts  and  academic 
research  has  matured  the  ideas  using  concept  engineering  for  agile  CONOPS  (Concept  of 
Operation)  Development.  Traditionally,  CONOPs,  functional  decompositions,  and  other 
qualitative  and  quantitative  methods,  were  employed  to  develop  requirements 
constraints  that  define  a  typically  large  set  of  feasible  system  realizations.  This  feasible 
region  is  then  explored  to  identify  a  subset  of  system  realizations  that  have  the  most 
preferred  operational  efficacy.  To  this  end,  system  objective  functions  are  constructed 
and  optimized  over  the  feasible  region  defined  within  the  boundaries  of  the 
requirements  and  constraints.  However,  for  both  contingency  basing  and  Soldier  load, 
when  realized  as  systems  of  systems  or  enterprises,  have  a  priori  uncertain  missions  and 
deployment  environment  requirements.  It  is  very  difficult  to  construct  a  requirements 
constrained  feasible  region  over  which  one  can  search  for  the  most  effective  operational 
regimes. 

Not  only  are  the  technology  mappings  dynamic,  but  also  the  number  of  requirement 
constraints  needed  to  capture  prior  uncertainties,  is  unmanageably  large.  Modern 
design  theory  suggests  systems  design  is  better  served  by  methodologies  that  focus  on 
constructing  objective  functions  with  penalties  that  capture  value  and  uncertainty,  as 
opposed  to  attempting  to  capture  the  unmanageable  large  number  of  requirement- 
constraints.  Consistent  with  RDECOM’s  vision  and  mission  to  be  the  Army’s  primary 
source  for  integrated  research,  development  and  engineering  capabilities  to  empower, 
unburden,  and  protect  the  Warfighter,  this  research  topic  calls  for  the  creation  of  an 
early  collaborative  and  system  models  to  express  and  characterize  Soldier  load  and 
contingency  basing  at  the  patrol  base,  combat  outpost,  and  small  combat  unit  (company 
minus)  level. 

The  long-range  vision  of  this  work  is  depicted  in  Figure  l  that  will  allow  for  capturing 
and  modeling  of  stakeholder  concerns  to  create  effective  systems  engineering  artifacts  in 
systems  modeling  and  CONOPS  to  enable  portfolio  management.  As  an  initial  proof  of 
concept,  this  sub-task  was  focuses  on  the  first  two  phases  of  this  work,  i.e.  Systemigrams 
and  System  Modeling,  as  depicted  in  Figure  l.  Thus,  this  research  sub-task  worked  with 
U.S.  Army  Natick  Soldier  RD&E  Center  (NSRDEC)  researchers  and  chief  engineers  to 
create  an  abstraction  of  the  whole  Contingency  Basing  and  Soldier  Load  scope  that  can 
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be  animated  at  a  early  stage  as  a  guide  to  identity  the  critical  components  and  aspects 
that  will  need  priority  of  scrutiny  in  order  to  create  high-fidelity  models.  This  was 
achieved  by  creating  high-level  systemigrams  and  system  models  for  Soldier  Load  and 
Contingency  Basing.  In  addition,  this  research  identified  means  to  create  initial 
value/risk  based  design  objectives  and  functions  on  a  reduced  (and  thus  manageable) 
constraint  space.  It  was  then  demonstrated  how  systemigram  models  can  be  used  to 
capture  key  dimensions  for  input  into  a  defined  SysML  tool  for  creating  better  systems 
engineering  artifacts.  The  following  sections  will  describe  this  effort. 


Capturing  &  Modeling 
Stakeholder  Concerns  to 
Enable  Portfolio 
Management 


Systemigrams 
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Figure  1:  Capturing  and  Modeling  Stakeholder  Concerns  to  Enable  Portfolio  Management 


Systemigrams 

Diagrams  that  try  to  capture  concepts  are  not  new  -  e.g.  concept  diagrams,  concept 
mapping,  fishbone  diagrams,  Senge’s  diagrams,  influence  diagrams,  and  even  of  course 
the  original  flow  charts.  The  one  thing  about  all  of  these  though  is  that  they  capture  the 
immediacy  of  prose  but  they  then  forget  that  and  move  on  to  the  next  local  piece  of 
knowledge.  It  is  more  difficult  to  find  longer  thought  threads  in  these  diagrams  since 
they  concentrate  on  linear  thinking  rather  than  holistic  thinking.  Senge’s  causal  loop 
diagrams  are  a  possible  exception  to  this  but  these  are  always  kept  deliberately  small 
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and  even  when  these  get  big  it  is  hard  for  the  reader  to  make  sense  of  the  totality  of  the 
language  that  the  diagram  conveys. 

The  existence  of  systemigrams  as  a  value-adding  proposition,  one  that  will  reveal  the 
inner  meanings  of  strategic  intent  and  help  build  a  greater  shared  understanding  in  a 
growing  community  of  people,  should  force  up  the  ante  for  defining  strategic  intent 
more  completely,  more  thoroughly,  more  thoughtfully,  and  more  purposefully.  There 
are  three  distinct  phases  in  the  evolutionary  process  for  developing  systemigrams: 

-  concentration  on  graphical  portrayal  of  structured  prose; 

-  development  of  methodologies  that  use  systemigrams  for  enterprise  architecting 
purposes,  e.g.  extended  enterprises  or  business  process  architectures; 

-  development  of  systemigram  technique  for  drilling  down  from  architectural 
vantage  points  into  detailed  consideration  of  solution  implementation 

The  creation  of  systemigrams  follow  the  Boardman  Soft  Systems  Methodology 
(BSSM)  of  seven  steps  that  can  be  viewed  as  an  iterative  process  for  defining  an  ill- 
defined  problem  (or  system  of  interest)  (Boardman  and  Sauser,  2008).  BSSM  is  useful 
for  understanding  motivations,  viewpoints,  and  interactions  and  addressing  qualitative 
dimensions  of  problem  situations.  The  seven  steps  of  BSSM  are  depicted  in  Figure  2 
followed  by  a  description  of  each  step  as  it  related  to  this  sub-task. 


Thr  Problem  Situation 

Unstructured 


\ 


Feasible,  Desirable 
Changes 


The  Problem  Situation 

Expressed 


Action  to  improve  the 
Problem  Situation 


Dramatisation  and 
Dialogue 

Comparison  of  4  to  2 


Ot**c  Sftttfm  TNnfcing 


Figure  2  -  Boardman  Soft  Systems  Methodology 


Step  1  -  The  Problem  Situation:  Unstructured:  The  problem  situation  is  first 
expressed  (textual,  verbal,  graphical),  as  it  is,  by  the  researcher  (or  stakeholder).  As  this 
step  can  be  based  on  many  presumptions,  every  attempt  is  made  not  to  extrapolate 
about  the  nature  of  the  situation.  We  made  every  attempt  to  understand  the  problem  by 
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investigating  the  situation  without  bias  from  RDECOM.  We  attempted  to  develop  a 
perspective  of  the  problem  with  our  own  largely  unbiased  view. 

Step  2  -  The  Problem  Situation:  Expressed:  In  this  step,  a  description  of  the 
situation  within  which  the  problem  occurs  is  formulated.  Both  logic  and  the  culture  of 
the  situation  are  taken  into  account  at  this  point.  Based  on  our  interpretations  from 
Step  l,  we  developed  an  expression  of  the  problem  based  on  a  review  of  relevant 
documentation  and  discussions  from  a  body  of  scholars  and  practitioners  in 
Contingency  Basing. 

Step  3  -  Structured  Text:  We  conceptualized  the  problem  situation  in  structured 
text.  The  Structured  Text  identified  the  key  elements  with  attention  to  systems  thinking 
modeling  and  analysis  requirements,  i.e.  systemigrams.  Using  this  body  of 
literature/knowledge  gained  from  Step  2,  we  were  able  to  write  a  document  that 
summarized  what  we  found,  what  was  similar,  and  what  was  different.  We  made  every 
attempt  to  not  change  the  original  words  or  thoughts  of  the  authors,  but  stay  true  to  the 
essence  of  their  views  on  the  problem.  This  became  the  source  text  of  our  systemigram. 

Step  4  -  Systemigram  Design:  We  created  a  systemigram  model  as  designed 
from  the  Structured  Text  to  capture  and  represent  the  essence  of  the  original  conceptual 
thinking.  A  systemigram  is  to  be  a  network,  having  nodes  and  links,  flow,  inputs,  and 
outputs,  beginning  and  end3.  This  must  fit  on  a  single  page.  Key  concepts,  noun  phrases 
specifying  people,  organizations,  groups,  artifacts  and  conditions  will  be  nodes.  The 
relationships  between  these  nodes  will  be  verb  phrases  (occasionally  prepositional 
phrases)  indicating  transformation,  belonging,  and  being.  Some  nodes  can  contain  other 
nodes,  for  example  to  indicate  break  out  of  a  document  or  an  organizational/ 
product/process  structure.  The  network  must  be  legible  so  that  this  limits  the  number  of 
nodes  and  links.  There  should  be  no  cross-over  of  links,  improving  clarity.  This 
constraint  further  lends  itself  to  systemic  design.  Such  a  network  tends  to  be  of  an 
interconnected  kind  for  which  the  ratio  of  nodes  to  links  is  1.5  or  thereabouts.  For  a 
systemigram  of  20  nodes,  the  total  number  of  possible  links  is  190,  whereas  the  actual 
number  will  be  about  30.  This  ratio  is  about  15%,  which  is  held  to  be  the  optimal  ratio  of 
interfaces  in  a  system  relative  to  how  many  there  could  be. 

The  primary  sentence  (mainstay),  which  supports  the  purpose  of  the  system  will  read 
from  top  left  to  bottom  right.  This  becomes  the  anchor  for  the  entire  visualization.  It  is 
used  to  help  the  viewer  understand  the  picture  as  a  whole.  The  other  segments  of  the 
systemigram  flow  out  of  and  back  into  this  mainstay,  connecting  as  needed  with  its 
landmark  noun  phrase  nodes  (see  Figure  3).  The  remaining  nodes  must  also  contain 
nouns  or  noun  phrases  (people,  organizations,  groups,  artifacts,  and  conditions).  The 
links  should  contain  verb  and  verb  phrases  (transformation,  belonging,  and  being).  As 


3  For  a  detailed  description  of  systemigrams,  see  Boardman,  J.  and  B.  Sauser.  (2008).  Systems  Thinking:  Coping  with 
21st  Century  Problems.  Boca  Raton,  FL:  Taylor  and  Francis/CRC  Press;  or  for  the  use  of  systemigrams  as  a  graphical 
CONOPS,  see  Cloutier,  et  al.  (2009).  Investigation  of  a  Graphical  CONOPS  Development  Environment  for  Agile 
Systems  Engineering .  Systems  Engineering  Research  Center  Final  Technical  Report,  Document  Number  SERC- 
2009-TR-003 
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the  Systemigram  is  realized,  it  should  capture  the  system  transformations  that  have  a 
structure  and  a  process. 


Figure  3  -  Systemigram  Mainstay 

The  geography  of  the  systemigram  can  be  exploited  to  say,  for  example  the  motivation 
for  the  strategic  intent,  its  mission,  and  how  it  will  be  accomplished  -  its  management. 
There  will  be  relationships  between  the  elements  of  each  of  these  -  the  why,  the  what 
and  the  how;  such  elemental  relationships  are  invaluable  for  maintaining  coherence  for 
accomplishing  the  strategic  intent.  Color  can  be  used  to  draw  attention,  in  a  consistent 
way,  to  sub-families  of  concepts  and  transformations.  However  the  finished 
systemigram  should  be  aesthetically  pleasing  and  in  line  with  the  3  top-level 
requirements,  which  moderates  its  form. 

Steps  5  -  Dramatization  and  Dialogue:  At  this  step  the  systemigram  model  is 
dramatized  via  storyboarding  to  the  stakeholders.  This  is  done  so  that  the  model  and 
reality  can  be  compared  and  contrasted.  The  differences  become  the  basis  for 
discussion:  how  things  work,  might  work,  and  what  are  the  implication?  Thus,  a 
completed  systemigram  is  not  the  end  of  the  story.  In  fact,  it  is  the  basis  for  telling  a 
story.  The  composer  of  the  systemigram  is  now  in  a  strong  position,  in  spite  of  any 
illiteracy  of  the  field  being  defined  that  he/she  may  have,  simply  because  it  takes 
considerable  comprehension  -  of  the  original  text  and  of  building  systems  -  to  complete 
the  systemigram.  The  story  can  be  told  in  a  variety  of  ways  but  all  have  the  same  generic 
format  -  to  create  a  storyboard  using  carefully  selected  scenes  which  are  sub-nets  of  the 
systemigram. 

This  storyboarding  helps  to  convey  the  message  of  the  systemigram,  together  with  the 
message  that  the  author  of  the  original  text  intended,  to  a  wider  audience.  Each  scene 
represents  a  key  part  of  the  message  but  by  the  same  token  it  begins  to  tell  a  more 
detailed  message  which  can  only  be  amplified  by  having  the  right  people  listen  to  the 
systemigram  story.  So  if  there  are  say  eight  scenes  then  in  principle  eight  detailed 
messages  can  be  generated,  all  at  a  lower  level  but  higher  amount  of  detail  than  the 
systemigram.  This  drilling  down  can  be  continued  for  as  long  as  required  or  until  the 
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messages  begin  to  fail  the  original  top-level  requirements  for  original  text  for 
systemigram  interpretation. 

This  is  a  very  important  step  for  verifying  the  systemigram  with  respects  to  its  ability  to 
capture  the  multiple  views  of  the  stakeholders.  The  dramatization  and  dialogue  was 
executed  in  a  series  of  meetings  with  RDECOM  stakeholders  at  NSRDEC.  At  this 
meetings  the  participants  were  presented  with  an  overview  and  tutorial  on  the  use  of 
systemigrams  as  a  systems  thinking  tool  so  as  to  stay  true  to  the  modeling  constraints. 
During  these  meetings  perspectives  (even  if  conflicting)  were  captured. 

Step  6  -  Feasible ,  Desirable  Changes:  At  this  step  the  identification  of  feasible 
and  desirable  changes  are  deciphered  from  the  previous  step,  understanding  that  they 
are  likely  to  vary.  Desirable  asks  if  it  is  technically  an  improvement?  Feasible  asks  if  it 
fits  the  culture?  It  is  common  for  Step  6  to  occur  after  Step  5  and  with  the  modeler 
deciphering  all  of  the  perspectives.  For  this  work,  we  were  able  to  make  changes  to  the 
systemigram  in  real-time  as  the  modeler  and  the  stakeholders  were  in  the  room 
collectively  utilizing  the  modeling  tool,  i.e.  SystemiTool. 

Step  7  -  Action  to  Improve  the  Problem  Situation.  Every  individual  or  collective 
input  that  is  deemed  Desirable  or  Feasible  is  incorporated  into  the  model.  Only 
contributions  that  answer  “no”  to  one  of  the  two  questions  presented  in  Step  6  are 
dismissed.  Likewise,  Step  7  was  executed  in  real-time  as  well. 

Steps  1-7  were  repeated  until  a  successful  outcome  of  a  BSSM  was  achieved. 
Success  is  defined  as:  (i)  the  people  concerned,  i.e.  stakeholders,  feel  that  the  problem 
has  been  solved;  or  (ii)  the  problem  situation  has  been  improved;  or  (iii)  insights  have 
been  gained.  What  resulted  from  this  effort  was  four  systemigrams  depicted  in  Figures 
4-7. 
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Figure  4:  Gunners  Systemigram 
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Figure  6:  Sustain  Small  Unit  Systemigram 
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Systemigrams  can  be  powerful  storytelling  aids  and  are  useful  in  providing  a  common 
foundation  for  group  discussions.  Another  value  of  systemigrams  is  that  they  do  not 
remove  the  complexity  from  systems,  but  they  can  make  complex  systems 
understandable.  See  Table  l  for  a  review  of  systemigram  construction  guidance. 
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Table  1-  Systemigram  Construction  Guidance 


Principle 

Systemigram  Guidance 

Correctness 

•  Mainstay  which  supports  the  purpose  of  the  system  reads  from  top  left  to  bottom 
right 

•  Ideally  there  should  be  1 5-2S  nodes 

•  Nodes  must  contain  noun  phrases 

•  Links  should  contain  verb  phrases  (to  reduce  trivial  links) 

•  No  repetition  of  nodes 

•  No  cross-over  of  links 

Relevant 

•  Remember  that  the  model  is  really  “theirs”. 

•  Remember  that  the  model  is  not  really  “theirs” 

•  Remember  that  the  model  is  not  reality 

Feasibility 

•  It  should  compare  to  reality  (comparing  4  to  2  in  the  BSSM) 

Clarity 

•  It  should  read  well. 

•  Beautification  (e.g.  shading  and  dashing  of  links  and  nodes)  should  help  the 
reader  read  the  sentences  in  the  diagram 

•  Exploit  topology  to  depict  why,  how,  what  ( who  when  and  where  is  built  into 
system  description) 

Comparability 

•  It  should  compare  to  reality  (comparing  4  to  2  in  the  BSSM) 

Systematic 

Design 

•  Is  it  a  system  in  its  own  right? 

•  Does  every  node  (except  for  the  beginning  and  ending  nodes)  have  an  input  and 
an  output? 

•  Can  you  follow  any  node  to  the  end  node  ? 

System  Modeling  Language 

The  systems  modeling  language  (SysML)  contains  a  number  of  diagrams  that  are  used 
to  capture  system  attributes,  operations,  tasks,  and  participants.  Figure  8  represents  the 
diagram  organization. 


Figure  8  -  SysML  Diagram  Structure 
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Each  diagram  can  be  used  to  capture  information  about  the  system  of  interest,  at  any 
level  or  multiple  levels  of  abstraction.  Each  group  of  diagrams  is  discussed  next. 

1.  Structure  (System)  diagram  represented  as  block  definition  diagrams  and 
internal  block  diagrams  identifies  the  physical  and  logical  layout  for  a  system. 

•  Block  definition  diagram  describes  the  system  hierarchy  and 
system/system  element  classifications.  Blocks  are  generally  nouns. 

•  Internal  block  diagram  describes  the  internal  structure  of  a  system  in 
terms  of  how  its  parts  are  inter-connected  using  ports  and  connectors.  Blocks 
are  generally  nouns. 

•  Package  diagram  is  used  to  organize  the  model  into  packages  that  contain 
other  model  elements. 

2.  Requirements  diagrams  capture  requirements  hierarchies  and  the  derivation, 
satisfaction,  and  verification  relationships.  Requirement  diagram  captures  the 
interrelationship  of  requirements. 

3.  Parametric  diagram  represents  constraints  on  system  parameter  values,  such 
as  performance,  reliability,  and  mass  properties  to  support  engineering  analysis. 

4.  Behavior  diagrams  include  the  following: 

•  Use-case  diagrams  provide  a  high-level  description  of  the  system 
functionality  in  terms  of  how  external  systems  use  the  system  under 
consideration  to  achieve  their  goals.  The  “use  cases”  generally  represent 
things  to  be  done,  and  the  actors  represent  nouns  in  the  form  of  either 
stakeholders  or  other  systems. 

•  Activity  diagrams  represent  the  flow  of  data  (artifacts,  which  are  nouns) 
and  control  between  activities. 

•  Sequence  diagrams  represent  the  exchange  of  information  between 
collaborating  parts  of  a  system  (which  are  nouns). 

•  State  diagrams  describe  the  states  of  a  system  or  its  parts  (nouns),  and  the 
transitions  between  the  states  in  response  to  triggering  events,  along  with  the 
actions  that  occur  upon  transition,  entry,  exit  of  while  in  the  state. 


Modeling  the  system  using  Systemigrams  and  SysML 

We  model  to  reason  about  the  problem,  to  understand  the  complexities,  and  to 
communicate  with  others  (R.  Cloutier).  This  research  was  to  explore  the  use  of 
systemigrams  and  SysML  to  accomplish  those  three  modeling  goals.  From  this  point 
forward,  we  will  look  at  the  process  of  initiating  a  SysML  diagram  from  a  systemigram. 
The  Soldier/SCU  systemigram  was  constructed  as  the  result  of  a  joint  workshop 
between  Drs.  Sauser  and  Cloutier  of  Stevens  Institute  and  subject  matter  experts  at  the 
Soldier  Center  in  Natick,  MA.  From  that  workshop,  the  top  level  Systemigram  was 
constructed,  and  decomposed  into  several  lower  level  Systemigrams. 
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Soldier/SCU  Systemigram 

1.  The  first  step  was  to  identify  the  nouns,  verbs,  and  adjectives  in  the  entire 
Systemigram  by  highlighting  each  with  a  different  color  (Figure  9). 

2.  Create  a  Domain  Diagram  for  the  System  (in  this  case  Soldier_SCU)  (Figure  10) 

3.  Connect  the  Nouns  in  the  Systemigram  to  the  System  in  the  Domain  Diagram 
accordingly. 


Figure  9  -  Soldier/SCU  Systemigram  with  annotations 
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bdd  Domain 


y 


Figure  10  -  Identified  Nouns  from  Soldier /SCU  Systemigram 

Next,  we  identify  the  use  cases  from  the  Systemigram 

1.  For  each  adjective  that  is  not  directly  linked  to  another  adjective  create  a  Use 
Case  Diagram  (Figures  11-15) 

2.  In  each  Use  Case  Diagram  use  the  adjective  to  create  a  Use  Case. 

3.  Each  Noun  (System)  that  is  linked,  in  the  Systemigram,  to  the  adjective  is 
connected  in  the  Use  Case  Diagram. 

4.  Include  Adjectives  that  are  connected  to  other  adjectives,  in  the  Systemigram,  as 
Use  Case’s  within  the  other  adjectives  Use  Case  Diagram  (see  Chronic  Injury  - 
Figure  12,  and  Mobility  -  Figure  14,  below  for  example). 
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uc  Acute  Injury ... 


Figure  11  -  Acute  Injury  Use  Case 


uc  Chronic  Injury ... 


Figure  12  -  Chronic  Injury  Use  Case 
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uc  Extended  Operations 


Figure  13  -  Extended  Operations  Use  Case 


Figure  14  -  Mobility  Use  Case 
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Figure  15  -  Vulnerability  Use  Case 

Understanding  the  Flow  of  Activities 

The  Systemigram  indirectly  represents  flow  of  events.  These  can  be  captured  in  SysML 
Activity  diagrams 

1.  Starting  at  the  upper  left  corner  of  the  Systemigram  follow  the  flow  of  the  main 
stories  (in  this  example  it  would  be  the  gold  and  green  paths).  Develop  an 
activity  diagram  detailing  the  flow  (Figures  16-17). 
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act  Encounter  "Threat 


Figure  16  Activity  Diagram  of  Gold  Path  in  Systemigram 
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act  Perform  Extended  Operations 


Figure  17  Activity  Diagram  for  Green  Path  in  Systemigram 


Decomposing  the  Problem 

Mentioned  earlier,  the  Soldier/SCU  Systemigram  represented  the  high  level  system. 
However,  it  could  be  decomposed  into  lower  level  Systemigrams  to  foster  more 
understanding.  Those  were:  1)  Sustain  Small  Unit  Systemigram,  2)  Gunners 
Systemigram,  and  3)  Soldier  Systemigram.  The  process  was  replicated  for  each  of  those 
Systemigrams,  as  discussed  below. 


Sustain  Small  Unit  Systemigram 

1.  Highlight  the  nouns,  verbs,  and  adjectives  in  the,  Sustain  Small  Unit 
Systemigram  (Figure  18). 
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Figure  18  -  Sustain  Small  Unit  Systemigram 


2.  For  each  adjective  that  is  not  directly  linked  to  another  adjective  create  the 
necessary  Use  Case  Diagrams  (Figures  19  and  20). 

3.  In  each  Use  Case  Diagram  use  the  adjective  to  create  a  Use  Case. 
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uc  Sustain  Small  Unit 


Figure  19  Sustain  Small  Unit  Use  Case 


uc  Resupply 


Figure  20  Resupply  Use  Case 
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4.  For  each  Use  Case  create  an  Activity  diagram  using  the  links  described  in  the 
systemigram  (Figures  21  and  22). 


Figure  21  Sustain  Small  Unit  Activity  Diagram 
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act  Resupply 


Figure  22  Resupply  Activity  Diagram 
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Gunners  Systemigram 


Figure  23  Gunner  Systemigram 

1.  Highlight  the  nouns,  verbs,  and  adjectives  in  the,  Gunners,  Systemigram  (Figure 

23). 

2.  Two  of  the  highlighted  use  cases,  Acute  Injury  and  Chronic  Injury,  in  pink  are 
recognized  as  already  being  developed  for  the  Soldier_SCU  Systemigram.  Since 
the  two  use  cases  are  already  developed  the  nouns  linked  to  each  use  case  are 
compared  to  those  already  connected  in  the  model.  It  is  recognized  that  Lethality 
System,  Mobility  System,  and  Gunners  should  be  added  to  the  Acute  Injury  Use 
Case  (see  Figure  24). 
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Figure  24  Updated  Acute  Injury  Use  Case  Diagram  for  Gunner  Systemigram 

3.  During  the  modification  of  the  Use  Case  diagram  it  is  discovered  that  Leathality 
System  and  Mobility  System  need  to  be  added  to  the  SoldierjSCU  Domain 
diagram.  The  two  systems  are  added  to  the  domain  diagram. 

4.  The  question  of  where  Gunners  should  be  represented  on  the  domain  and  actor 
diagrams  is  not  resolved  since  they  are  not  represented  together  in  any 
Systemigram. 

5.  Next  the  Chronic  Injury  use  case  is  updated  to  include  the  Leathality  and 
Mobility  Systems  (see  Figure  25). 
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uc  Chronic  Injury ... 


Figure  25  Updated  Chronic  Injury  Use  Case  for  Gunner  Systemigram 

6.  A  new  use  case  was  created  for  Echelon  Protection  (see  Figure  26). 


uc  Echelon  Protection 
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Figure  26  Echelon  Protection  Use  Case 

7.  Starting  at  the  upper  left  of  the  Gunner  Systemigram  the  Operate  as  part  of  the 
Teams  Squads  Platoons  activity  diagram  is  identified  by  the  outgoing  link  (main 
path)  from  Gunners. 

8.  The  Teams  Squads  Platoons  activity  diagram  was  created  (see  Figure  27)  by 
following  the  main  path  in  the  Systemigram  plus  adding  in  additional  links  that 
flowed  from  objects  in  the  main  path  of  the  Systemigram. 


act  Responsible  for  Echelon  Protection 


Figure  27  Operate  as  part  of  Teams  Squads  Platoons  Activity  Diagram 

9.  The  next  path  that  is  analyzed  from  the  Systemigram  is  Responsible  for  Echelon 
Protection  (Figure  28).  This  path  is  turned  into  an  activity  diagram  using  the 
flow  and  links  shown  in  the  Systemigram. 
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act  Operate  as  Teams 


Figure  28  Responsible  for  Echelon  Protection  Activity  Diagram 


Soldier  Systemigram 

1.  Highlight  the  nouns,  verbs,  and  adjectives  in  the,  Soldiers,  Systemigram  (see 
Figure  29). 
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Figure  29  Soldier  Systemigram 

2.  Two  of  the  highlighted  use  cases,  Acute  Injury  and  Chronic  Injury,  in  pink  are 
recognized  as  already  being  developed  for  the  Soldier_SCU  Systemigram.  Since 
the  two  use  cases  are  already  developed  the  nouns  linked  to  each  use  case  are 
compared  to  those  already  connected  in  the  model.  It  is  recognized  that  Mission 
Command  should  be  added  to  the  Acute  Injury  Use  Case  (Figure  30)  and  Chronic 
Injury  Use  Case  (Figure  31). 
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uc  Acute  Injury ... 


Figure  30  Updated  Acute  Injury  Use  Case  for  Soldier  Systemigram 
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Figure  31  Updated  Chronic  Injury  Use  Case  for  Soldier  Systemigram 

3.  It  is  noticed  while  updating  the  use  case  diagrams  that  Mission  Command  needs 
to  be  added  to  the  Domain  diagram.  The  domain  diagram  is  updated  to  include 
Mission  Command. 

4.  Starting  at  the  upper  left  of  the  Soldier  Systemigram  the  Performs  Extended 
Operations  activity  diagram  is  identified  by  the  outgoing  link  from  Soldiers. 

5.  The  Performs  Extended  Operations  Activity  Diagram  was  created  (see  Figure  32) 
by  following  the  path  in  the  Systemigram. 
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act  Perform  Extended  Operations 


Figure  32  Performs  Extended  Operations  Activity  Diagram 


Transformation  Challenges 

During  this  research,  the  team  found  there  were  certain  relationships/links  on  the 
Systemigram  that  do  not  translate  well.  For  instance,  “resulting  from”  and  “quantified 
in”  links  are  difficult  to  model.  Other  challenges  to  consider  when  translating  a 
Systemigram  to  SysML  include: 

(1)  The  relationship  within  the  overall  domain  can  be  hard  to  translate.  For  example 
in  the  set  of  Systemigrams  used  for  this  exercise  we  have  a  gunner  and  a  soldier 
but  nowhere  in  any  of  the  diagrams  is  that  relationship  described.  So  in  the  final 
domain  diagram  “Leader”  is  not  connected  because  from  the  Systemigram  it  is 
unknown  if  a  “Leader”  is  a  soldier  or  the  exact  relationship  is. 

(2)  At  the  current  time  nodes  such  as  “Leaders”  in  the  “Gunners”  Systemigram  that 
appear  in  the  middle  of  Systemigram  but  have  no  input  links  (only  outputs)  are 
not  translated  into  SysML  diagrams 

The  lesson  learned  here  is  that  when  decomposing  Systemigrams,  it  is  important  to  not 
reuse  nodes  at  the  different  levels  of  Systemigrams  unless  they  are  exact  nodes. 
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3  Model  Based  Systems  Engineering 


Introduction 

This  collaborative  work  was  conducted  by  researchers  at  the  University  of  Virginia  and 
the  Fraunhofer  Center  for  Experimental  Software  Engineering.  Input,  feedback,  and 
resources  describing  Army  contingency  bases  (CBs)  were  provided  by  experts  from 
PEOs  within  the  Office  of  the  US  Assistant  Secretary  of  the  Army  for  Acquisition, 
Logistics,  and  Technology  (ASA(ALT)  and  the  Army  Corps  of  Engineers.  This  work  is  a 
companion  to  the  ASA(ALT)  Contingency  Basing  Initiative  -  an  ongoing  effort  to 
establish  a  contingency  basing  Program  of  Record. 


Problem  Statement 

This  part  of  this  project  addressed  two  research  and  development  problems  in  the 
systems  engineering  of  Army  Contingency  Basis  (CB). 

First,  CB  planning  efforts  are  producing  a  diversity  of  partial,  often  not  well  validated, 
not  well  reconciled,  and  non-interoperable  CB  models.  This  state  of  affairs  complicates 
the  tasks  of  designing,  provisioning,  operating,  and  evolving  CBs  by  deny  designers  the 
tools  needed  to  adequately  analyze,  update,  and  employ  valid,  comprehensive  models. 
Models  developed  to  date  include  models  of  cost,  functional  decomposition,  structure 
and  behavior  using  SysML,  dynamic  logistics  (Sandia),  and  now  Systemigram  models, 
as  introduced  above.  These  models  are  in  turn  represented  concretely  within  a  variety  of 
modeling  tools  and  formalisms  without  the  benefits  of  consistency  maintenance  through 
tool  interoperability. 

Second,  the  complexity  of  CB  modeling,  design,  and  operation  is  greatly  complicated  by 
the  extensive,  often  poorly  understood  coupling  of  diverse  concerns,  particularly  when 
such  concerns  are  handled  by  separate,  "siloed"  organizations  within  the  US  Army.  The 
problem  is  that  when  decisions  that  are  coupled  in  actuality  are  optimized  in  isolation, 
the  outcomes  at  the  system  level  are  often  far  from  optimal.  A  minimal  approach  to  this 
problem  requires  far  better  mapping  (representation)  of  concerns  and  coupling  among 
concerns  (e.g.,  power,  water,  and  so  forth),  so  that  system-level  consequences  of  local 
decisions,  actions  and  conditions  can  be  reasoned  about  effectively.  A  more  far-reaching 
approach  involves  the  restructuring  of  dependencies  through  improved  modularization 
of  CB  designs  and  operations.  Even  when  dependencies  are  understood,  overly  tight  and 
extensive  coupling  creates  significant  problems,  particularly  by  limiting  the  capacity  for 
and  increasing  the  cost  of  and  time  required  for  CB  adaptation  and  evolution. 
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Project  Goals 

We  formulated  goals  for  the  pair  of  model-based  systems  engineering  tasks,  taken  as  a 
cohesive  project.  First,  we  sought  to  develop  a  conceptual  framework  implemented  in  an 
early  prototype  modeling  tool  through  which  we  could  start  to  reconcile  and  represent 
and  reconcile  important  concepts  found  in  the  diverse  current  models,  and  in  terms  of 
which  we  could  explicitly  represent  coupling  relationships  among  them  in  a  computable, 
analyzable  form.  These  concerns  include  definitions  of  key  measures  of  CB  performance 
(outcome  parameters),  external  conditions  (environment  parameters),  and  parameters 
over  which  CB  designers  and  operators  have  control. 

Central  to  this  effort  was  explicit  attention  to  the  issue  of  coupling  both  within  and 
among  environment,  design/decision,  and  outcome  parameters,  even  if  only  in  informal 
(as  opposed  to  precise  mathematical)  terms.  For  example,  in  early  stages  of  modeling, 
we  aim  for  it  to  be  possible  to  model  coupling  of  decisions  about  locale,  water  supply, 
power,  and  resupply  demand  without  the  usability  burden  of  mathematical  precision. 

The  explicit,  even  if  informal,  representation  of  coupling  relationships  among  explicit, 
even  if  informally  described  system  parameters  is  at  central  to  our  work.  It  is  necessary 
for  human  reasoning  about  the  effects  of  decisions,  for  automated  analysis  of  coupling 
and  modularity  properties,  and  to  support  decision-making  about  any  restructuring  of 
CB  designs,  operational  activities,  and  supporting  organizations  and  their  interactions. 

In  addition  to  providing  a  capability  for  modeling  coupling  of  technical  parameters,  as 
described  above,  we  also  aimed  for  a  framework  in  terms  of  which  we  could  model  the 
organizational  structures  that  support  CBs.  Our  premise,  based  on  our  task  definitions, 
was  that  separate  organizational  units  often  handle  separate  CB  parameter  decisions, 
and  that  these  decisions  are  often  not  sufficiently  well  coordinated,  leading  to  outcomes 
that  are  significantly  suboptimal  in  important  dimensions.  Our  modeling  approach  thus 
explicitly  represents  organizational  roles  and  the  mapping  of  these  roles  to  technical 
(environment,  decision,  and  outcome)  parameters.  The  coupling  among  the  technical 
parameters  can  then  be  used  to  reason  about  required  interactions  for  coordination 
among  the  supporting  organizational  units.  Our  goal  was  to  enable  reasoning  about 
required  interactions,  comparisons  between  required  and  actual  interactions,  and  thus 
about  the  possible  need  for  interventions  and  courses  of  action  relevant  to  achieving 
adequate  coordination  of  decision  making  in  the  design,  operation,  and  evolution  of 
CBs. 

Next,  we  aimed  to  provide  a  prototype  of  "social"  modeling  tool:  one  that  distributed 
modelers  engaged  in  developing  such  models  could  use  collaboratively  in  the  process  of 
determining  what  are  pertinent  system  parameters,  relationships,  roles,  assignments  of 
responsibility,  and  consequences  of  given  structures  and  assumptions.  We  thus  sought 
to  produce  a  prototype,  web-  and  cloud-computing-based  modeling  environment  for 
these  purposes.  To  this  end  we  adapted  and  significant  developed  technology  that  we 
produced  in  our  labs  by  earlier  research. 


Contract  Number:  H98230-08-D-01 71  TO  001 0,  RT  033 

Report  No.  SERC-2012-TR-033 
November  30,  2012 


43 


UNCLASSIFIED 


Finally,  we  aimed  to  validate  our  modeling  approach  and  the  tool  support  developed  for 
it  through  empirical  study  and  early  experimental  applications  in  the  CB  domain. 


Approach 

Our  approach  was  in  two  parts.  The  University  of  Virginia  took  primary  responsibility 
for  developing  the  conceptual  underpinnings  and  technological  for  modeling  in  the  style 
presented  above.  The  Fraunhofer  Institute  team  took  the  lead  on  empirical  investigation 
and  evaluation.  With  the  technology  developing  at  the  same  time  as  the  empirical  work 
was  conducted,  Fraunhofer  sought  to  develop  CB  models  grounded  in  the  best  data  that 
was  available  to  our  team,  including  interviews  with  CB  subject  matter  experts,  with  an 
emphasis  on  identifying  technical  and  organizational  parameters  and  their  coupling  and 
mapping  relationships,  but  without  an  attempt  to  map  results  strictly  into  the  University 
of  Virginia  framework.  The  University  of  Virginia  sought  to  evolve  the  conceptual  model 
and  prototype  tooling  to  the  point  we  could  being  to  evaluate  its  use  for  CB  modeling,  to 
identify  any  shortcomings,  and  to  drive  an  incremental  and  evolutionary  modeling  and 
software  development  process  based  on  mutual  interaction.  The  teams  interacted  on  a 
regular  basis  and  these  interactions  informed  the  activities  of  each  group  throughout  the 
period  of  our  project.  We  also  had  numerous  on-site  meetings  with  the  subject  matter 
experts  at  our  sponsoring  site,  as  well  as  regular  telecons  with  other  organizations  that 
were  participating  in  the  Army  CB  effort.  The  remainder  of  this  section  described  the 
methods  and  outcomes  of  this  joint  research  and  development  activity. 


Empirical  Exploration  and  Building  of  Contingency  Base  models 

Our  empirical  work  aimed  first  to  map  key  CB  issues  through  interviews  with  subject 
matter  experts,  available  documentation,  and  other  means,  and  then  to  map  the  results 
broadly  into  the  modeling  framework  discussed  herein.  In  this  section,  we  describe  our 
process  for  extracting  models  of  contingency  base  environment,  decision,  and  outcome 
parameters,  as  well  as  organizational-to-technical  parameter  mappings. 


Modeling  goals 

The  impetus  for  this  work  was  an  initiative  on  the  part  of  our  sponsors  to  improve  the 
effectiveness  and  efficiency  of  decision  making  in  planning  and  operation  of  US  Army 
CBs.  Decision  processes  include  many  tacit  relationships  and  multiple  stakeholders 
whose  relationships  are  not  always  clearly  defined.  For  CBs,  these  decision  processes  are 
primarily  captured  in  Army  guidance  documents  (standards,  handbooks,  regulations) 
and  in  expert  knowledge.  We  sought  to  build  CB  models  in  a  scientifically  rigorous  way. 

Goal  1:  To  define  a  rigorous  analytical  method  for  extracting  models  of  decision 
making  processes  from  qualitative  sources; 

Goal  2:  To  create  useful  models  of  Contingency  Basing  decision  processes  that 
capture  the  variables,  relations,  and  stakeholders  involved  in  the  decision. 
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To  have  confidence  in  our  CB  modeling  activity  (the  results  of  Goal  2),  our  analytical 
method  (Goal  1)  addresses  five  model-building  challenges  identified  in  our  proposal: 

Challenge  1:  Define  scope  -  An  analysis  of  this  type  requires  a  common  unit  of 
analysis  so  that  key  concepts  can  be  identified  and  analyzed  across  different 
documents,  even  if  referred  to  under  different  terminology.  Our  units  of  analysis  are  the 
resources  that  are  consumed  or  generated  by  a  Contingency  Base.  We  adopted  the  set 
of  8  resources  identified  in  the  functional  decomposition  model  created  by  other 
members  of  ASA(ALT)’s  CB  project. 

Reconciling  the  ontologies  that  are  implicit  in  the  multiple  models  and  documents  we 
encountered  is  a  key  challenge  for  a  CB  modeling,  analysis,  and  design  improvement 
initiative.  Our  results  suggest  that  the  general  form,  and  perhaps  web-based  aspects  of 
our  framework  and  tooling,  have  significant  potential  to  assist  in  this  fundamental 
aspect  of  model  integration  and  analysis.  Eventually  a  formal  approach  to  ontology, 
even  if  only  for  the  most  essential  concepts,  seems  to  be  an  activity  worth  considering. 

Challenge  2:  Cohesion  -  The  models  developed  must  be  internally  consistent  so  that 
they  can  be  more  easily  understood  and  useful.  Our  analysis  is  iterative,  beginning 
with  a  semi-unstructured  series  of  questions  to  extract  model  components,  followed  by 
analysis  of  component  relationships,  leading  to  more  structured  questions  as  important 
concepts  begin  to  emerge. 

Challenge  3:  Consistent  vocabulary  -  Experts  from  different  functional  areas  may  use 
different  terms.  The  concepts  elicited  must  be  mapped  to  one  another  consistently 
despite  differences  in  the  technical  vocabularies  to  develop  a  consistent  vocabulary 
that  brings  key  concepts  together. 

Challenge  4:  Traceability  -  The  source  of  each  individual  finding  must  be 
identified  so  that  we  have  traceability  back  to  the  original  source  to  elicit  more  details 
if  needed,  as  well  as  a  mechanism  for  resolving  potential  discrepancies  among  sources. 
(If  two  different  sources  present  incompatible  information  about  decision  making,  it 
may  be  that  each  is  accurate  but  only  if  different  domains  /  contexts.) 

Challenge  5:  Verified  -  Results  of  such  an  analysis  should  be  repeatable  -  not  simply 
the  result  of  one  person’s  opinion  or  (potentially  biased)  understanding  of  the  problem 
domain.  Our  analysis  was  conducted  by  three  researchers  independently  and  the 
findings  triangulated  and  discussed  to  obtain  confidence  in  the  results. 


Modeling  approach  -  Iterative  document  analysis  and  coding 

Our  model-building  approach  relied  on  a  rigorous  qualitative  analysis  technique  known 
as  coding.  Coding  is  a  well-accepted  technique  that  extracts  concepts  from  qualitative 
data  by  attaching  “codes,  or  labels,  to  pieces  of  text  that  are  relevant  to  a  particular 
theme  or  idea  of  interest”  [Seamanoy].  Coding  outputs  a  set  of  concepts  that  can  be 
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arranged  hierarchically  (at  different  levels  of  abstraction)  and  form  the  basis  of  the  basic 
ontology  necessary  to  develop  a  mapping  between  various  domains  and  terminology. 

For  example,  in  prior  work,  we  used  similar  techniques  to  create  a  hierarchical  model  of 
information  sources  (e.g.  documentation,  local  experts,  etc.)  and  the  ways  these 
resources  are  used  in  software  maintenance  in  the  aerospace  domain  [Seamano2, 
Luttersc>7].  Coding  analysis  is  appropriate  for  qualitative  sources  of  information  that  are 
in  a  narrative  of  semi-structured  form,  such  as  the  guidance  documents  and  regulations 
we  used  as  sources  of  data.  We  now  describe  the  source  materials  used  in  our  coding 
analysis  and  provide  a  detailed  description  of  the  analysis  steps. 


Source  materials 

To  identify  and  model  the  variables  and  stakeholders  involved  in  the  decision  process  of 
contingency  base  planning,  we  proposed  to  build  our  models  based  on  both  Army  CB 
documentation  (standards/guides)  and  on  interviews  with  Army  CB  experts.  These 
resources  would  provide  the  best  sources  of  information  that  cover  a  broad  swath  of  CB 
decisions,  rather  than  focus  on  specific  aspects  of  CB  operations  (e.g.  power  generation 
and  optimization).  Unfortunately  due  to  availability  constraints  of  the  experts,  we  were 
not  able  to  conduct  these  interviews. 

We  applied  coding  to  the  following  documents  to  obtain  an  overview  on  the  decision 
hierarchy  and  potential  stakeholders  involved  in  the  decision  process  of  contingency 
base  planning: 

•  ATTP  q-.q7.10/MCRP  3-17.7N  -  Base  Camps:  “a  compilation  of  tactics, 
techniques,  and  procedures  (TTP)  found  in  doctrine,  lessons  learned,  and  other 
reference  material  that,  for  the  first  time,  provides  an  integrated  systematic 
approach  to  base  camps.  It  codifies  the  recent  efforts  of  the  Base  Camp  Integrated 
Capabilities  Development  Team  as  part  of  the  Army  capabilities-based 
assessment  process  and  serves  commanders  and  their  staffs  as  a  comprehensive 
‘how-to’  guide  for  performing  all  aspects  of  the  base  camp  life  cycle  during 
deployments.” 

•  Army  Corps  of  Engineers  Base  Camp  Development  EP  1105-3-1  -  Base  Camp 

Development  in  the  Theater  of  Operations:  focuses  primarily  on  the  engineer- 
specific  areas  of  base  camp  planning,  such  as  selecting  a  location,  and 
documentation  needed  for  a  base  camp  in  any  geographic  area. 

•  Joint  Forward  Operations  Base  (JFOB)  Force  Protection  Handbook:  designed  as 
a  quick  reference  guide  for  a  systematic  approach  to  planning,  developing,  and 
improving  JFOB  defensive  capabilities  to  counter  threats  to  JFOBs  in  Iraq  and 
describes  best  practices  based  upon  lessons  learned  in  Iraq. 

•  US  Army  R  415-1  -  Construction  and  Base  Camp  Development  in  the 
USCENTCOM  Area  of  Responsibility  (‘The  Sandbook’):  describes  basic  standards 
for  the  construction  of  base  camps.  The  document  is  aimed  at  engineering  units 
at  forces  and  contract  authorities.  The  Sandbook  is  mostly  a  subset  of  the 
information  in  the  JFOB  Handbook. 
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•  Contingency  Basing  Functional  Decomposition:  an  analysis  of  the  functional 
capabilities  required  of  a  VFOB  (Very  Large  Forward  Operating  Base)  prepared 
by  members  of  the  ASA(ALT)  Contingency  Base  project. 


Modeling  process 

Our  modeling  process  is  summarized  in  the  steps  below. 

1.  Identity  unit  for  analysis 

2.  Independent  document  analysis 

a.  Identity  variables,  relations,  and  stakeholders 

b.  Merge  similar  terms 

c.  Organize  variables  into  groups  (e.g.  facilities,  mission  parameters, 
activities,  facilities,  decision  nodes) 

3.  Compare  findings  from  individuals 

4.  Collate  model  components  from  multiple  sources 

5.  Identity  dependencies  and  model  relationships 

6.  Build  visual  models 

Step  1:  Identify  unit  for  analysis  -  The  scope  of  the  decisions  made  in  CB  planning 
and  operations  was  too  large  to  model  given  our  available  resources.  Thus,  we  focused 
on  specific  resource  areas  as  identified  in  the  Army’s  CB  Functional  Decomposition 
(FD).  The  FD  identified  eight  resource  areas:  power,  fuel,  base  footprint,  building 
footprint,  waste,  water,  food,  and  network.  We  focused  on  the  decision  hierarchies  two 
resources,  water  and  fuel,  as  well  as  the  decisions  involving  the  operation  of  a  medical 
facility.  We  chose  these  resources  based  on  the  diverse  concerns  and  dependencies  in 
water  and  fuel  management  as  communicated  to  us  in  meeting  with  the  Army  CB 
project  team  and  because  these  resources  frequently  appeared  in  the  source  materials  as 
examples.  Water  and  fuel  supply  and  management  are  central  to  planning  and  running 
a  base,  and  water  in  particular  is  well  documented.  Medical  facilities  are  sufficiently 
complex  to  show  the  use  of  those  two  resources  and  the  complexity  of  the  decision 
process  while  giving  some  pointers  to  other  resources  used  or  produced  that  need  to  be 
accounted  for  when  planning. 

Step  2:  Independent  document  analysis  -  Each  document  from  Section  o  was 
assigned  to  two  Fraunhofer  researchers  to  perform  coding  analysis  on  independently. 

We  searched  and  read  these  documents  for  keywords  related  to  fuel  (e.g.  fuel,  coal,  gas, 
petrol,  generator),  water,  and  medical  facilities.  We  extracted  and  coded  text  according 
to  the  following  parts  of  the  decision  space  model: 

•  Variables  (Parameters)-  white  water,  gray  water,  black  water,  billeting,  dining, 
laundry,  maintenance,  construction,  waste  water  transportation,  potable  water 
distribution,  weather,  temperature,  threat  level,  etc. 

•  Relations  -  e.g.,  self-reliant  water  production  REDUCES  supply  line  strain; 
personal  water  container  type  IMPACTS  waste  management  cost. 

•  Stakeholders  -  e.g.  Base  Camp  Commander,  logistics  staff  officer,  safety  officer. 
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After  applying  the  codes,  similar  terms  were  merged,  for  example  “drinking  water”  and 
“potable  water”  are  very  similar,  as  are  “jet  fuel”  and  “JP8”.  After  merging  similar  terms, 
the  variables  were  organized  into  groups.  For  example,  white  water,  gray  water,  and 
black  water  were  grouped  under  “Water  type”,  while  billeting,  dining,  and  laundry  were 
grouped  under  “facilities”.  These  groups  allowed  for  a  more  easy  conceptual 
understanding  of  the  elements  of  a  CB. 

Step  3:  Compare  findings  from  individuals  -  In  this  step,  the  group  met  to 
compare  the  results  of  the  coding  analysis.  Agreement  was  generally  high,  though  the 
reviewers  for  a  given  document  may  not  overlap  completely.  The  codes  were  merged  to 
form  a  complete  set  -  in  no  case  did  the  reviewers  disagree  about  the  coding  of  a 
particular  section  after  the  group  discussion.  The  combined  set  of  codes  for  each  source 
document  was  used  as  the  basis  for  the  model  building. 

Step  4:  Collate  model  components  from  multiple  sources  -  The  variables, 
relations,  and  stakeholders  from  each  document  were  combined  to  paint  a  more 
complete  picture  of  the  fuel,  water,  and  medical  facility  management  on  a  CB.  During 
this  step,  it  became  obvious  that  no  one  source  material  provided  all  of  the  information 
needed  to  understand  the  complete  picture  of  the  decisions  involving  water,  fuel,  or 
medical  facilities.  This  is,  perhaps,  not  surprising,  but  is  indicative  of  the  challenges 
facing  CB  planners:  all  of  the  considerations  that  go  into  a  decision  are  seemingly  not 
laid  out  in  one  cohesive  source  reference. 

Step  5:  Identify  dependencies  and  model  relationships  -  Our  coding  activities 
yielded  a  set  of  key  concepts  related  to  each  resource  which  is  important  for  contingency 
base  planning  and  the  relationships  among  these  areas.  We  extracted  decision 
hierarchies,  potential  stakeholders  involved  in  those  decisions  or  sub  decisions,  as  well 
as  dependencies  or  relationships  that  may  impact  the  actual  decisions  or  have  to  be 
considered  when  making  these  decisions.  In  the  models,  these  constraints  or 
relationships  appear  as  parameters.  We  distinguish  between  the  following  parameters: 

•  Environment  parameters,  i.e.,  parameters  that  describe  the  situation  and  can’t  be 
changed,  such  as  threat  level,  geographic  location,  or  minimum  amount  of 
drinking  water  required  per  person  per  day 

•  Decision  parameters,  i.e.,  parameters  that  can  be  changed  or  modified,  in  order 
to  obtain  different  results,  such  as  the  number  of  water  deliveries  scheduled  per 
week,  number  of  people  planned  on  base,  the  number  and  types  of  facilities  to  be 
built,  if  water  is  to  be  provided  by  a  well  or  sent  in  by  truck,  and 

•  Performance  parameters,  i.e.,  quality  parameters  that  are  impacted  by  the 
decision  parameters,  such  as  tank  size  needed  on  base,  amount  of  fuel  consumed 
by  the  facilities,  amount  of  food  needed 

Step  6:  Build  visual  models  -  We  visually  modeled  the  fuel,  water,  and  medical 
facility  decision  spaces  to  support  more  useful  analysis.  The  textual  responses  from  each 
expert  were  transformed  into  a  graphical  representation.  The  use  of  diagrams  has  shown 
to  be  extremely  useful  not  only  in  capturing  processes  and  flows,  but  also  when 
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reviewing  the  resulting  models  with  experts  [Cordingly89].  A  major  part  of  decision 
making  in  general  involves  analyzing  the  available  alternatives  described  in  terms  of 
cost  (or  constraints  on  making  a  decision)  and  benefit.  Detailed  cost /benefit  or 
constraint  analysis  requires  expert  opinion.  To  show  the  key  elements  of  the  decision 
process  in  our  models,  we  therefore  decided  to  represent  decisions  and  sub  decision 
nodes,  along  with  costs/benefits/constraints  associated,  and  stakeholders  who  may  be 
able  to  provide  this  analysis.  The  visualization  step  provided  a  helpful  means  of 
representing  the  information  gained,  both  for  our  own  analysis  and  as  a  useful  artifact 
that  can  be  applied  during  later  interactions  with  experts  to  better  elicit  their  knowledge 
and  feedback. 


Relationship  to  other  models  being  worked 

We  designed  our  modeling  and  visualization  approach  to  complement  and  eventually  to 
integrate,  not  to  duplicate,  other  ongoing  work  in  the  Army’s  Contingency  Basing 
initiative.  Other  models  being  worked  include: 

1.  A  low-level,  executable  model  of  resource  consumption  and  production  by  Sandia 
National  Labs.  This  model  can  be  executed  to  identify  the  effects  of  various 
resource  allocations. 

2.  A  model  of  the  number  of  resources  necessary  to  establish  CBs  of  different  sizes 
developed  by  the  Army  Corps  of  Engineers.  The  model  helps  to  understand  the 
resource  cost-drivers  in  CB  operation. 

3.  A  functional  decomposition  that  maps  contingency  base  requirements  (e.g. 
project  the  force,  collect  intelligence  histories)  to  inputs,  outputs,  and  loads.  This 
model  is  used  as  one  of  our  source  documents. 

In  contrast,  each  of  our  models  shows  a  more  high-level  view  of  the  decisions  to  be 
taken  for  planning  of  that  resource  or  facility.  The  models  would  enable  a  decision 
maker  to  have  a  unified  view  of  decisions  that  are  spread  out  over  different  parts  in 
different  guidebooks.  We  based  our  models  on  the  guidebooks,  because  they  are  already 
distilled  versions  of  the  key  decisions  to  make  and  dependencies  to  take  into  account 
and  are  vetted  and  approved  by  stakeholders  and  can  thus  be  seen  as  common 
understanding.  These  guidebooks  can  be  assumed  to  be  the  core  information  available 
to  any  base  commander  or  decision  maker  to  start  out  with  when  planning  a  base. 


Contingency  base  models 

Based  on  the  information  available  in  the  guidebooks,  we  captured  information  related 
to  the  two  resources  water  and  fuel,  and  a  medical  facility  to  see  how  the  use  of  these  ties 
in  with  decision  modeling  of  an  actual  facility.  Our  "empirically  based"  models  (meant 
to  feed  into  our  novel  modeling  formalism)  show  the  decisions  to  be  taken  in  the  course 
of  the  planning  process  along  with  interfaces  and  dependencies  or  follow-up  decisions, 
as  extracted  in  the  guidebooks. 


Contract  Number:  H98230-08-D-01 71  TO  001 0,  RT  033 

Report  No.  SERC-2012-TR-033 
November  30,  2012 


49 


UNCLASSIFIED 


Water  Modeling 

The  documents  distinguish  between  white  water  -  fresh,  potable  water,  grey  water  - 
water  that  is  typically  relatively  easy  to  treat,  such  as  laundry  or  showers,  and  black 
water  -  any  water  containing  human  waste.  Accordingly,  we  developed  a  model  each  for 
white  water,  grey  water,  and  black  water,  following  the  steps  described  in  o. 

The  main  problem  -  how  to  provide  potable  water  of  sufficient  amount,  quality,  and 
price  -  can  be  broken  down  into  several  sub  decisions,  such  as  a  decision  on  what 
source(s)  to  use,  how  the  water  will  be  transported,  or  how  to  ensure  water  quality. 

Figure  33  shows  the  decision  hierarchy  of  how  to  provide  whitewater  of  sufficient 
quality  and  at  the  required  amount  at  given  cost  in  contingency  base  planning  and  how 
this  decision  is  broken  down  in  sub  decisions  -  modeling  the  decision  process  of  a 
contingency  base  planner.  One  of  the  contributions  of  this  "empirical"  modeling  to  the 
development  of  our  conceptual  modeling  formalism  was  to  emphasize  the  need  for 
hierarchically  structured  sets  of  system  parameters.  This  in  turn  led  to  a  key  insight  for 
future  development  of  our  conceptual  modeling  approach  and  supporting  tool:  that  we 
can  leverage  the  theory  of  types  (from  the  disciplines  of  programming  languages  and 
software  engineering)  to  inform  the  design  of  our  modeling  framework  and  tools.  This 
insight  is  very  clearly  reflected  in  carefully  documented  plans  for  a  "version  two"  of  our 
initial  prototype  tool. 

Our  empirically  derived  models  in  this  area  are  based  on  different  documents. 
Therefore,  we  found  it  important  that  information  in  the  model  can  also  be  traced  back 
to  the  original  sources  and  viewpoints.  Thus,  any  information  taken  from  the  Army’s 
Base  Camp  101  was  drawn  in  blue,  information  taken  from  the  Army  Corps  of  Engineers 
Handbook  is  drawn  in  red,  and  information  taken  from  the  JFOB  Handbook  is  drawn  in 
green.  The  need  for  traceability  of  abstractly  modeled  decision  (and  other)  parameters 
to  original  source  materials  is  a  second  insight  leading  to  a  requirement  to  be  handled  in 
the  ongoing  evolution  of  our  conceptual  modeling  approach  and  toolset. 

In  the  diagram,  dotted  lines  show  decisions  that  might  not  always  have  to  be  taken.  For 
instance,  the  decision  on  the  water  source  would  in  most  cases  only  require  one  of  its 
sub  decisions,  water  supplied  by  well,  or  water  by  contractors  or  water  by  purification 
unit. 

Note,  that  we  added  a  decision  node  that  was  not  mentioned  in  any  of  the  documents  to 
the  diagram  -  decide  on  distribution  of  water  across  facilities.  We  decided  that  an 
important  aspect  of  overall  base  planning  is  to  decide  how  water  distribution  across 
different  facilities  will  be  negotiated  in  case  it  is  a  scarce  or  limited  resource.  When  a 
planner  walks  through  one  of  these  decision  hierarchies,  each  of  these  decisions  and  sub 
decisions  is  impacted  by  parameters  that  may  need  to  be  considered  when  making  the 
decision.  For  instance,  the  decision  to  use  a  well  as  a  water  source  requires  a  a  local 
aquifer.  Some  decisions  may  impact  further  decisions.  For  instance,  if  a  purification  unit 
is  to  be  used,  additional  power  sources  will  be  required  as  a  consequence.  In  our 
diagrams,  these  parameters  and  relationships  between  the  parameters  and  the  decision 
nodes  show  as  trapezoids  (parameters  and  relationships  are  summarized  into  one  shape 
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to  increase  legibility)  and  color-coded  according  to  the  source  document  the  information 
was  extracted  from  (blue  for  Army’s  Base  Camp  101,  red  for  Army  Corps  of  Engineers 
Handbook,  and  green  for  the  JFOB  Handbook). 


In  addition,  every  single  one  of  these  decisions  and  sub  decisions  is  impacted  by  mission 


Figure  33:  Whitewater  decision  hierarchy  with  constraints 


Note  that  we  found  inconsistent  information  when  comparing  the  amount  of  water 
required  per  person  and  per  day  in  two  different  documents.  Whereas  the  Army  Base 
Camp  101  document,  which  is  based  upon  experience  in  desert  environment,  mentions 
60  gal  -  240  quarts  -  of  potable  water  per  person  and  day,  the  Army  Corps  of 
Development  mentions  a  required  9  quarts  of  water  per  day.  Driving  toward  a  canonical 
representation  of  information  in  terms  of  environment,  decision,  and  outcome  variables, 
organizational  units,  mapping  of  responsibilities,  and  coordination  requirements  at  the 
organizational  level  induced  by  coupling  of  technical  parameters  is  showing  itself  to  be  a 
useful,  systematic,  and  fundamental,  method  for  integrating  existing  models  and  related 
documents. 
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Apart  from  the  inconsistency  mentioned,  information  drawn  from  different  documents 
differs  in  level  of  detail.  For  instance,  the  Army  Corps  of  Engineers  Handbook  provides  a 
lot  more  detail  the  type  of  water  analysis  to  be  performed.  However,  the  handbook  lacks 
guidelines  on  how  the  detailed  analysis  of  water  is  used,  and  how  it  impacts  further 
decisions,  e.g,  what  to  do  if  a  data  point  is  above  the  threshold. 

Making  an  informed  decision  often  requires  a  planner  to  take  into  account  expert 
knowledge.  Therefore,  many  other  stakeholders  are  involved  in  the  decision  process.  A 
major  goal  of  our  work  relates  to  the  social  network  required  to  ‘traverse’  the  decision 
hierarchy. 

Figure  34  shows  the  (same)  decision  hierarchy  of  whitewater  supply  with  its  associated 
stakeholders  involved  in  each  level  of  decisions.  The  diagram  uses  ovals  to  show 
stakeholders;  blue  ovals  for  stakeholders  as  identified  from  the  Army’s  Base  Camp  101, 
red  ovals  for  stakeholders  taken  from  the  Army  Corps  of  Engineers  Handbook,  and 
green  ovals  for  stakeholders  taken  from  the  JFOB  Handbook. 

Some  stakeholders  only  come  into  play  under  certain  circumstances,  for  instance,  a 
water  resource  analyst  is  only  needed  in  situations  where  water  is  a  scarce  resource.  In 
the  model,  these  stakeholders  are  drawn  with  dotted  lines,  along  with  a  note  under  what 
circumstances  these  stakeholders  are  involved. 
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Figure  34:  Whitewater  decision  hierarchy  with  stakeholders  involved 

The  stakeholders  are  taken  from  the  documents,  thus  they  don’t  always  correspond  to 
roles  (i.e.,  a  set  of  responsibilities  or  skills  necessary  to  perform  a  task),  but  sometimes 
positions  or  divisions. 

Although  supplying  of  water  has  several  options  for  water  sources  -  contractors,  well, 
surface,  purification  unit  -actual  stakeholders  couldn’t  be  extracted  from  the 
documentation.  However,  a  decision  maker  who  has  to  find  feasible  water  sources  might 
need  to  know  who  can  provide  their  expertise  in  selecting  a  water  source  or  ruling  out  a 
water  source. 
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Figure  35  shows  the  whitewater  decision  tree  with  the  parameters  and  stakeholders 
involved  -  a  combined  view  of 
Figure  33  and 
Figure  34. 

The  diagram  shows  the  complex  relationships;  many  stakeholders  are  involved  in  the 
decision  hierarchies  and  in  the  different  aspects  of  providing  water,  and  for  each 
decision  many  parameters  have  to  be  taken  into  account.  It  seems  that  it  is  almost 
impossible  for  a  single  individual  to  make  an  informed  decision,  given  all  the  additional 
parameters  that  need  to  be  taken  into  account. 

Some  parameters  are  tied  to  more  complex  decisions.  For  instance,  the  decision  if  water 
comes  from  a  well,  surface  water  or  other  sources  has  a  lot  of  detailed  decision 
parameters  associated  with  it  that  impact  the  decision  (e.g.,  ‘whether  a  well  can  be  used 
depends  on....’  -  ‘whether  surface  water  can  be  used  ...’).  For  these  decisions,  expert  or 
stakeholder  involvement  would  be  expected  at  two  levels  -  running  the  analyses  and 
providing  the  data  to  the  decision  maker,  and  then  interpreting  the  data  to  help  the 
decision  maker  determine  which  water  sources  are  feasible.  However,  the  guidebooks 
do  not  mention  any  additional  stakeholders  or  experts  who  could  support  the  decision 
maker.  For  instance,  one  would  expect  a  water  analyst  to  be  involved  in  such  a  complex 
and  important  decision. 
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Figure  36  shows  the  decision  hierarchy  for  black  water,  together  with  stakeholders 
involved  in  the  decisions.  The  decision  hierarchies  include  questions  on  treatment,  and 
holding/storage.  The  main  parameters  influencing  how  black  water  is  treated  and 
stored  are  the  mission  parameters.  Sewage  handling  has  an  impact  on  risk  analysis, 
however,  we  did  not  find  explicit  stakeholders  attached  to  any  of  the  decisions. 

Black  water  has  additional  ties  to  white  water,  as  contamination  of  agricultural  areas 
and  water  supplies  need  to  be  prevented. 
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Figure  37:  Graywater  decision  hierarchy 


Figure  37  shows  the  decision  hierarchy  for  gray  water,  together  with  stakeholders 
involved  in  the  decisions.  The  decision  hierarchies  includes  questions  on  treatment, 
holding/storage,  and  on  further  use  of  gray  water.  The  decision  points  for  gray  water  are 
very  similar  to  the  ones  for  black  water.  Possible  further  use  of  gray  water  is  mentioned, 
however,  parameters  influencing  that  decision  arenot  explicitly  mentioned  in  any  of  the 
reports. 
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Black  and  gray  water  are  a  lot  less  documented  than  white,  the  distinction  between  black 
or  gray  water  is  not  always  clear  in  reports.  Altogether,  the  decision  hierarchy  of  gray 
water  is  not  much  different  from  the  black  water  decision  hierarchy. 

Black  and  gray  water  may  be  treated  the  same  way,  although  reports  claim  that  recycling 
gray  water  might  be  more  energy-efficient  or  that  recycling  gray  could  reduce  logistics 
requirement  by  using  gray  water  for  wash  racks  or  toilets.  These  would  indicate  an 
additional  relationship  with  energy  or  logistics/ white  water  use. 
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Fuel  Modeling 


Figure  38:  Fuel  decision  hierarchy 


The  overall  decision  -  on  howto  provide  fuel  (sufficient  amount,  quality,  type...)?  is 
broken  down  into  the  sub  decisions  decide  on  fuel  type,  decide  on  fuel  supply,  decide  on 
fuel  use,  decide  on  adequate  storage,  and  take  into  account  environmental 
considerations,  as  shown  in  Figure  38.  Although  environmental  considerations  were 
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not  explicitly  mentioned  as  a  decision  point  in  the  reports  we  decided  to  group  several 
environmental  considerations  addressed  in  the  report  under  that  decision  node. 

Note  that  these  sub  decisions  are  not  independent  of  each  other.  For  instance,  the  type 
of  fuel  that  will  be  needed  has  an  impact  on  the  way  it  will  be  stored,  storage  location  is 
impacted  by  where  fuel  will  be  used,  and  use  of  fuel  depends  on  the  type  of  fuel 
available.  Thus,  although  these  nodes  are  separate  sub  decisions,  they  can’t  be  traversed 
completely  independently  of  each  other. 


Figure  39:  Fuel  Type  decision  hierarchy 


Figure  39  shows  the  decision  nodes  related  to  the  decision  of  what  type  of  fuel  to 
provide  -  fuel  oil,  gas,  or  liquid  petroleum  gas.  Information  on  different  types  of  fuel 
and  the  parameters  that  impact  fuel  types  were  only  mentioned  in  the  Army  Corps  of 
Engineers  Handbook,  and  in  the  context  of  heating  fuel.  The  parameters  are  rather 
complex,  however,  we  could  not  identify  any  stakeholders  in  the  document  who  might 
be  able  to  provide  expert  knowledge  on  whether  the  constraints  are  fulfilled. 
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Typically  requires  tank 
car/tank  truck  to  bring  in 


availability 


Unit  cost 


if  gas  or  oil  are  used 


May  be  provided 
under  contract 


Impacted  by  outstanding 
oil,  gas,  mineral  rights 


Impacted  by  est. 
cost  of 
construction 


Note:  these  were  mentioned 
in  relation  to  heating  fuel, 
maybe  applies  to  all  other  fuel 
types  or  uses 


hether  gas  or  oil  can  be  used  depend  on: 

Distance  to,  size  of,  and  pressure  in  nearest  pipeline  or  point  of  supply. 

Maximum  amount  of  gas  or  oil  that  can  be  supplied. 

Available  reserves  for  10-year  demand.  BTU  content  of  gas  or  grade  of  oil. 

If  a  new  pipeline  and/or  other  facilities  must  be  built  to  bring  a  sufficient  quantity 
of  gas  to  the  boundaries  of  the  location,  give  length,  size,  time  of  connection,  and 
approximate  cost  of  line  and  other  facilities  that  must  be  constructed  at 
government  expense. 

Determine  extent  to  which  gas  company  will  cooperate  in  providing  necessary 
extensions  that  will  provide  adequate  supply  at  minimum  cost  to  the  government./ 
Pressure  of  gas  that  the  company  can  maintain  at  point  of  delivery 
at  boundary  of  location. 

Names  and  addresses  of  utility  companies  supplying  gas. 

Rates  at  which  gas  can  be  procured.  Character  of  soil  in  area 
through  which  proposed  gas  lines  must  be  installed. 


Figure  40:  Fuel  supply  decision  hierarchy 


Figure  40  shows  the  decision  hierarchy  for  fuel  supply.  The  only  stakeholder  identified 
is  vehicle  management.  On  the  other  hand,  a  lot  of  parameters  were  identified,  such  as 
construction  costs,  or  existing  rights.  A  lot  of  background  knowledge  would  be  required 
to  evaluate  these  parameters,  but  no  stakeholders,  who  would  be  able  to  provide  expert 
knowledge,  are  listed.  For  instance,  with  construction  costs  as  one  parameter  in  the 
decision  of  fuel  supply,  one  would  expect  a  construction  expert  to  be  involved  to 
estimate  those  costs. 
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Figure  41:  Fuel  use  decision  hierarchy 


Figure  41  breaks  the  decision  on  how  fuel  will  be  used  down  onto  different  facilities  as 
identified  from  the  documents.  Fuel  is  used  for  equipment,  vehicles,  burn  out  latrines, 
incinerators,  heating,  aviation,  and  power  generation.  As  a  side  effect,  facilities,  such  as 
vehicle  refueling  may  have  an  impact  on  the  overall  number  of  people  on  base 
throughout  the  day,  possibly  triggering  the  need  for  further  decisions  in  other 
hierarchies.  Our  diagrams  use  the  wavy  scroll  shape  to  indicate  interfaces  with  other 
decision  nodes,  such  as  Waste  management.  Interfaces  with  other  decision  hierarchies 
identified  include  burn  out  latrines  and  incinerators  (interfacing  with  waste 
management). 

With  so  many  requirements  on  location  one  would  expect  a  planner  or  resource 
manager  to  be  involved  in  the  decision,  or  stakeholders  of  the  different  facilities,  giving 
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an  estimate  on  needs,  or  requirements  on  location.  However,  the  only  stakeholder 
explicitly  identified  from  docs  is  aviation  unit  involved  in  aviation  refueling. 
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Figure  42  shows  the  decision  hierarchy  for  fuel  storage.  It  is  broken  down  into  decisions 
about  amount  needed,  type  of  storage,  and  storage  location.  The  Sandbook  mentions 
environment  protection  as  a  part  of  storage  location,  but  not  stakeholder  itself; 
therefore,  the  stakeholder  ‘Environment  specialist’  was  added  in  the  diagram  (using  a 
yellow  oval  for  a  stakeholder  extracted  from  the  Sandbook). 

The  majority  of  all  parameters  are  related  to  storage  location  as  taken  from  all  three 
documents.  This  matches  the  stakeholders  involved  in  the  decision.  For  instance,  the 
location  ‘needs  to  be  protected  from  theft  and  destruction...’  and  involves  critical 
supply/infrastructure  as  a  stakeholder.  Most  parameters  related  to  storage  location 
affects  overall  camp  layout.  This  is  reflected  by  involving  the  planner  as  a  stakeholder  in 
the  decision. 

A  lot  of  the  (decision)  parameters  -  such  as  ‘needs  to  be  away  from  living  quarters  ‘,  or 
‘needs  to  be  easy  to  observe’  are  vague  and  therefore  difficult  to  verily. 
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Figure  43  summarizes  all  sub  decisions  related  to  environmental  considerations, 
namely,  decisions  on  how  to  prevent  spills,  decisions  on  how  to  avoid  pollution  due  to 
combustion,  decisions  related  to  clean  up,  and  decisions  related  to  subsurface  drainage. 
The  sub  decision  ‘howto  avoid  pollution...’  is  mentioned,  however,  no  further 
information  in  terms  of  stakeholders  or  parameters  could  be  found  in  the  documents. 
Several  parameters  guiding  environmental  decisions  are  related  to  overall  base  camp 
planning,  however,  no  base  camp  planner  is  involved  in  the  decision. 
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One  sub  decision  relates  to  planning  of  base  camp  cleanup,  interfacing  with  the  entire 
decision  hierarchy  related  to  base  camp  cleanup. 


Medical  Facility  modeling 

To  put  fuel,  white,  gray,  and  black  water  into  a  larger  context,  we  modeled  a  facility  that 
would  use  or  produce  all  of  these  entities.  We  decided  on  a  more  complex  facility,  that 
would  have  additional  interfaces  beyond  water  and  fuel  and  modeled  a  medical  facility 
and  the  resources  used  and  produced. 


Figure  44:  A  Medical  facility  key  relationships 


In  order  to  show  how  some  of  the  entities  modeled  above  fit  into  the  bigger  picture  of  a 
sample  facility,  Figure  44  shows  the  key  relationships  modeled  for  a  medical  facility.  A 
medical  facility  needs  white  water,  e.g.,  for  food/drinking  or  sterilizing.  It  produces 
warm  or  hot  gray  water,  e.g.,  from  cooling,  sterilizing  or  showers,  and  black  water,  from 
toilets.  In  addition  to  those  two  variations  of  wastewater,  a  medical  facility  produces 
medical  waste  and  requires  power  to  run. 
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Figure  45:  Waste  Management  decision  hierarchy 


A  key  issue  for  medical  facilities  is  how  to  handle  medical  waste. 

Figure  45  shows  how  this  decision  is  broken  down  in  to  sub  decisions  and  shows  the 
stakeholder  involved.  Decisions  related  to  medical  waste  removal  can  be  refined  into  the 
decisions  related  to  storage,  and  disposal  type.  Medical  waste  removal  in  general 
becomes  an  issue  in  camp  cleanup  and  may  lead  to  additional  workload. 

The  only  stakeholders  found  are  BOC/Facilities/Medical  and 

BOC/Facilities/Environment  in  the  context  of  waste  storage.  Waste  disposal  is  either 
handled  by  civilian  contractors  or  through  incinerators  -  interfacing  with  fuel 
management  (see  Figure  41). 
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Model  extraction  summary 

This  section  summarizes  our  findings  from  developing  the  models. 

Complex  models:  Even  such  a  small  excerpt  of  overall  base  planning  with  a  very 
limited  scope  becomes  complex,  and  already  at  this  high  level  of  detail. 

Consistency  of  information:  With  one  exception,  we  did  not  encounter  inconsistent 
information  across  different  documents.  This  was  also  due  to  the  fact  that  there  was  not 
much  overlap  between  the  individual  documents. 

Coverage:  On  the  other  hand,  we  did  not  discover  much  overlap  between  documents. 
This  also  raises  the  question  of  completeness.  We  analyzed  3  documents,  but  it  is  not 
clear  if  this  set  of  documents  is  sufficient  to  cover  all  relevant  aspects  of  water,  fuel  or 
medical  facilities  or  are  we  missing  relevant  information  because  it  wasn’t  covered  in 
any  of  these  reports.  Would  additional  documents  confirm  findings  or  could  an 
additional  document  add  relevant  information  not  yet  covered? 

Stakeholder  mapping:  Constraints  are  not  always  aligned  with  stakeholders  (e.g.,  a 
decision  may  have  a  relationship  tied  to  water  analysis,  but  the  corresponding 
stakeholder  with  technical  expertise  is  not  explicitly  involved  in  the  decision.  In  fuel 
modeling  almost  every  sub  decision  is  related  to  location  and  overall  camp  layout. 
However,  no  stakeholder  related  to  that  layout  planning  in  relation  to  fuel  could  be 
extracted  in  relation  to  fuel.  Stakeholders  are  missing,  or  if  mentioned,  are  not 
consistently  defined  as  stakeholders,  but  sometimes  a  hybrid  between  role  and  position 
or  division. 

Interconnected  decision  nodes:  It  is  difficult  to  completely  follow  through  on  the 
decision  hierarchy  of  one  resource  without  the  other  as  they  are  tightly  coupled 
interconnected.  For  instance,  white  water  may  require  fuel  to  generate  energy  to  purify 
water,  fuel,  on  the  other  hand,  can’t  be  planned  without  taking  water  (groundwater)  into 
account.  The  decision  for  a  single  entity  can’t  be  done  independently  as  there  will  be 
further  dependencies  as  you  traverse  down  the  decision  hierarchy.  This  can  eventually 
lead  to  the  question  where  to  start  as  it  may  lead  to  a  deadlock  situation.  This  may  lead 
to  a  situation  where  facilities/resources  can’t  be  planned  independently  of  each  other, 
but  may  have  to  be  planned  in  parallel.  Even  sub  decisions  related  to  an  individual 
resource  or  entity  (such  as  whitewater  water  or  fuel  supply)  can’t  always  be  modularized 
as  there  are  sometimes  interrelationships  with  other  sub  decisions  of  that  entity. 

Parameters:  It  is  not  always  obvious  how  to  determine  which  parameter  to  make 
decision  and  which  one  to  make  performance  parameter.  A  lot  of  parameters  impact  one 
another,  and  depending  on  the  targeted  result,  a  performance  parameter  can  be 
switched  with  its  associated  parameter  (e.g.,  the  set  of  planned  facilities  using  fuel  has 
an  impact  on  the  type  of  fuel  I  need  to  provide,  but  on  the  other  hand  the  type  of  fuel  I 
can  provide  has  an  impact  on  the  type  of  facilities  I  will  be  able  to  run).  Depending  on 
the  targeted  situation  and  decision  to  take,  both  seem  to  be  feasible  classifications.. 

Contract  Number:  H98230-08-D-01 71  TO  001 0,  RT  033 

Report  No.  SERC-2012-TR-033 
November  30,  2012 


68 


UNCLASSIFIED 


It  would  be  interesting  to  develop  a  decision  model  for  energy  use,  supply,  and 
distribution  on  a  base  as  such  a  model  would  be  closely  integrated  with  and  builds  upon 
the  existing  models  for  fuel  and  puts  it  into  a  wider  context,  but  can  be  expected  to  have 
a  lot  of  interdependencies  with  other  resources,  such  as  water.  In  addition,  this  model 
might  help  to  better  understand  how  to  deal  with  highly  interconnected  decision  nodes. 

Guidance  for  decision  makers:  Our  modeling  tasks  showed  that  the  information 
needed  to  make  an  informed  decision  is  scattered  across  several  documents,  making  it 
difficult  for  decision  makers  to  gather  the  information  needed  to  make  the  decision.  The 
resulting  decision  models  are  powerful  tools  to  provide  an  overall  picture  of  the  decision 
hierarchy  and  provide  guidance  through  the  steps  of  decision-making.  A  combined  and 
consolidated  view  of  the  decision  process  and  the  stakeholders  involved  allows  a 
decision  maker  to  see  at  one  glance,  who  is  impacted  by  a  decision,  and  who  can  provide 
the  expertise  needed  at  decision  point.  The  models  help  a  novice  base  planner  ensure 
that  all  sub  decisions  are  taken,  all  relevant  stakeholders  needed  to  obtain  a  complete 
picture  of  the  problem  are  considered,  and  gives  an  overview  of  dependencies. 

Understanding  through  traceable  models:  A  graphic  notation  makes  the  models 
rather  intuitive.  Due  to  the  level  of  abstraction  chosen  for  the  models  sub  decision,  their 
dependencies  and  stakeholders  are  understandable  and  traceable  for  users  and  allow 
them  to  find  additional  information  in  documents. 

Integrate  stakeholders  into  decision  process:  Modeling  showed  that  decision 
making  is  extremely  complex  and  involves  many  stakeholders  at  different  levels  of  the 
decisions.  The  models  can  be  used  to  bring  different  stakeholders  involved  in  decisions 
together  by  painting  an  overall  picture  of  the  decision  process  and  showing  how  one 
small  (sub)  decision  fits  into  the  overall  process,  and  what  other  stakeholders  are 
involved.  Furthermore,  the  models  can  be  used  as  a  basis  to  extract  role-specific  views  of 
the  decision  process  to  show  stakeholders  where  they  play  a  role  in  the  decision  process 
without  overwhelming  them  with  unnecessary  information. 

Quality  of  handbook:  Extracting  information  from  the  documents  showed  that  even 
the  combined  information  from  different  handbooks  is  not  always  sufficient  to  yield  a 
complete  picture  of  the  decision  hierarchy.  The  models  developed  can  be  used  to 
support  developers  or  providers  of  cb  planning  handbooks  to  identify  information 
missing  in  the  handbooks  and  to  yield  better  quality  in  the  documents. 


Tool  Support  for  Our  Collaborative  Conceptual  Modeling  Approach 
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Figure  46:  Screen  Shot  of  CB-Decider,  a  web-based  collaborative  modeling  environment 


Figure  46  presents  a  screen  shot  of  a  minimalistic  CB  model  linking  water,  power  and 
waste  decision  parameters  both  to  each  other  and  to  decision  makers  (here  modeled  as 
Kevin  Sullivan  and  Lucas,  but  in  general  these  would  be  organizational  roles).  There  is  a 
very  simple  relation  coupling  water  and  power  decisions.  This  coupling  is  reflected  in 
the  computed  decision  structure  matrix,  and  the  inferred  need  for  coordination  coupling 
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between  Kevin  and  Lucas  is  displayed  in  the  computed  "social  (organizational)  structure 
matrix." 

The  tool  is  designed  and  implemented  as  a  modern,  interactive,  and  collaborative  web 
application.  Its  persistence  layer  is  implemented  using  a  scalable,  document-oriented, 
no-SQL  database.  The  business  layer  is  presented  as  a  REST  web  service.  The  interactive 
client  software  (as  in  Figure  46)  is  a  rapid  prototype  that  runs  as  Javascript  entirely  in 
the  user  browser.  Updates  made  through  a  client  to  the  underlying  data  are  reflected 
immediately  on  the  screens  of  all  participating  collaborators  in  the  style  of  Google's 
"Google  Doc"  collaborative  editing  system.  The  underlying  computational  connectors 
are  Ajax,  Comet,  Web  Sockets. 

Our  research  and  development  activities  in  this  project  included  extended  use  of  this 
technology  to  build  a  variety  of  test  models.  This  experience  suggests  that  at  least  to 
start,  the  most  effective  use  of  the  tooling  is  either  by  a  single  modeler,  or  by  a  group  of 
modelers  who  work  together  online  with  supplementary  interactions  provided  using 
telephones,  Skype,  or  other  ordinary  means  of  interaction.  We  observed  that  in  our 
modeling  efforts,  having  to  express  issues  in  the  terms  of  our  conceptual  framework  of 
system  parameters,  relationships,  participants,  mappings,  and  then  being  able  to  see  the 
consequences  in  terms  of  coupling  and  coordination  diagrams  tended  to  highlight  areas 
of  implicit  inconsistency,  and  to  drive  us  to  focus  on  documenting  the  critical  issues  in 
ways  that  were  understandable  and  that  led  to  a  shared  vision  of  the  systems  issues  in 
play  in  the  CB  domain. 

This  tool  and  its  underlying  formalism  was  also  carefully  designed  to  achieve  a  balance 
between  two  competing  pressures.  On  the  one  hand,  it  would  be  nice  to  have  precise  and 
detailed  mathematical  models  of  relationships  and  systems  of  relationships,  so  as  to  be 
able  to  compute  predictions  and  properties  of  CB  designs,  and  of  tradeoffs  in  this  space, 
with  precision  and  rigor.  On  the  other  hand,  in  the  early  stages  of  modeling  and  model 
reconciliation  and  integration,  we  find  that  what  is  most  important  is  simply  fostering  a 
process  of  convergence  of  agreement  on  what  basic  terms  mean,  what  parameters  and 
relationships  are  most  important,  and  what  are  the  technical  coupling  and  organization 
structure  implications  that  might  dictate  future  courses  of  action  in  terms  of  CB  design 
or  organizational  refactoring,  and  what  improved  forms  of  modularity  in  the  structure  of 
coupling  relationships  might  greatly  reduce  the  costs  of,  and  provide  much  improved 
opportunities  for,  system  adaptation  and  evolution  to  changing  conditions,  or  the  needs 
for  improved  CB  performance.  Our  relationship  objects  are  thus  explicitly  linked  to  their 
corresponding  parameter  objects,  but  the  semantics  of  relationships  are  left  informal. 


4  Conclusion  and  Future  Work 


The  decision  processes  of  contingency  base  planning  and  operation  are  complex.  The 
decision  models  and  supporting  methods  developed  by  this  research  task,  based  on 
Army  guidance  documents  and  other  CB  models,  are  multi-layered,  involve  numerous 
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variables,  and  in  many  cases  have  an  ill-defined  set  of  stakeholders.  For  both  sub-tasks 
we  have  only  scratched  the  surface  of  discovering  the  core  issues  or  defining  a 
methodology.  Despite  limiting  ourselves  to  the  example  areas  (i.e.  water  management, 
fuel  management,  medical  facility  management,  and  solider  load  for  SCU)  from  CB 
documentation  and  key  stakeholders,  the  decision  spaces  uncovered  are  complex 
enough  that  even  experienced  CB  planners  would  be  hard-pressed  to  understand  the  full 
ramifications  of  their  decisions,  especially  if  given  limited  planning  resources.  One  goal 
of  this  effort  was  to  understand  the  relationships  between  stakeholders  involved  in  CB 
decisions.  While  the  source  documents  we  researched  contained  some  indications  of 
organization  at  the  base  camp  level,  there  was  little  description  of  the  personnel  whose 
duties  placed  them  in  charge  of  the  variables  involved  in  a  decision.  We  suspect  that  this 
is  due  to  the  variable  natures  of  CBs  themselves:  duties  are  distributed  according  to  the 
size  of  and  personnel  available  on  each  CB  at  a  particular  point  in  time.  Nonetheless, 
building  the  systemigrams,  SysML,  social  network  of  roles  that  are  responsible  for 
variables  in  a  decision  (both  those  variables  that  serve  as  input  into  a  decision  and  those 
that  are  impacted  downstream  by  a  decision)  is  beneficial  for  the  decision-maker,  who 
must  know  who  to  contact  for  the  latest  information. 

Originally  we  had  thought  that  an  important  aspect  of  this  work  would  be  identifying 
and  resolving  disagreements  and  conflicting  information  and  defining 
system  boundaries  among  the  experts.  Since  contingency  bases  are  complex  entities 
that  require  expertise  from  different  technical  domains,  we  had  expected  to  find 
different  views  of  the  world  (which  may  be  incompatible)  and  partial  views  of  the  overall 
solution.  In  actuality,  we  found  very  few  such  disagreements.  We  expect  that  this  was 
due  to  the  fact  that  the  different  sources  we  were  able  to  leverage  all  dealt  with  different 
aspects  of  planning;  thus,  while  they  provided  coverage  over  the  larger  decision-making 
process  they  typically  were  designed  for  different  stakeholders  and  did  not  often  cover 
the  same  parts  of  that  process.  The  responses  to  our  modeling  efforts  from  members  of 
the  Contingency  Basing  Initiative  have  been  positive.  Our  hope  it  to  reengage  the  CB 
initiative  in  2013  after  its  reorganization  in  late  2012.  The  CB  Initiative  members  have 
suggested  that  the  social  network  and  decision  modeling  may  be  of  particular  use  for 
operational  energy  distribution  (i.e.  both  power  and  fuel)  decisions  among  multiple 
contingency  bases  within  an  Area  of  Operations.  More  broadly,  we  believe  our  rigorous 
qualitative  analysis  coupled  with  the  decision  space  modeling  and  analysis  provide  a 
novel  and  useful  means  for  understanding  and  describing  the  latent  decision  structures 
the  compose  most  planning  and  operation  activities. 
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